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distinct flow, one at ingress and one at egress, and two other 
counters at the egress per each measured flow. It is also 
efficient, as it can achieve any degree of accuracy with little 
implementation cost. This method can be applied to a wide 
range of switch/router designs where simple and fast hard- 
ware implementation is desirable. 
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FIG. 5 
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METHOD AND APPARATUS FOR PACKET 
LOSS MEASUREMENT IN PACKET 
NETWORKS 

BACKGROUND 

In various communications networks user information is 
carried in packets that are routed from the source to the 
destination via switches. A switch buffers each packet 
received from upstream sources until a decision is made 
when and to which outgoing link the packet need to be 
forwarded. Since the buffer space is always finite, packets 
could be dropped within a switch when buffer overflow 
occurs or when packets with a lower priority class have to 
give way to those with a higher priority class. In applications 
where a particular quality of service is desired or promised, 
it is obviously important for a switch to monitor packet 
losses incurred within the switch. Moreover, routing proto- 
cols require this information to be advertised within a 
network or a group of nodes, to facilitate path selections and 
to avoid congestion. 

A high speed switch can generally be represented by a 
multi-stage interconnection where an N plurality of ingress 
modules are connected to a central switch fabric, and the 
outputs of the switch fabric are connected to an N plurality 
of egress modules. Each ingress and each egress module 
couples K input links and output links, respectively. Links 
carry streams of packets, where the destination of each 
packet is specified in the packet's header. 

High speed switches of such construction typically 
include buffering within each of the elements (ingress 
modules, switching fabric, and egress modules). A packet 
received from an incoming link is first buffered at the ingress 
module, where a table lookup typically takes place to find 
out the egress module which the packet is destined to. In 
such an implementation, a local routing header will nor- 
mally be placed in the front of the received packet. The local 
routing header may contain a number of information fields 
that are necessary to route the packet through the switching 
fabric, including the identity of the output link to which the 
packet needs to be routed. The extended packet is then 
dispatched to the desired egress module through the high 
speed, where some local buffering may be necessary. At the 
egress module, the packet is buffered until the outgoing link 
becomes available to transmit the packet. The local routing 
header is removed in the egress module before the packet is 
transmitted. 

In a hierarchical communication network, a set of inter- 
connected switches, each having the construction described 
above, can be unified in a logical group of nodes. From the 
network point of view, this logical group of nodes itself 
represents a generalized switch with input modules, output 
modules and generalized switching fabric. The network 
itself is a generalized switch on the highest level of hierar- 
chy. Each logical group of nodes can maintain an internal 
routing header. 

In this configuration, the packet could be lost in any of 
multiple locations within the ingress module, the switching 
fabric, or the egress module. The loss can be caused by 
buffer congestion, priority control, usage parameter control 
or a random electrical glitch leading to mis-routing, delin- 
eation error, checksum error, etc. 

It is of practical interest, as indicated above, to be able to 
know whether, and how many, packets are lost within a 
switch or a logical group of nodes. It is of even greater 
interest to associate a packet loss with a particular traffic 
flow within the generalized switch. 
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SUMMARY OF THE INVENTION 

This disclosure presents a simple and effective approach 
to the local packet loss measurement that is oriented to 
packet flows rather than the loss sources and allows to 
achieve high precision in a distributed switching environ- 
ment with multiple loss reasons and multiple loss locations. 
The loss measurements are achieved by selecting the par- 
ticular traffic flow, or flows, to be measured, identifying 
those flows in the ingress modules, marking each of the 
flows, and observing the packets of the flows at the egress 
modules. More specifically, a packet flow to be measured is 
broken into blocks of packets, and the last packet in the 
block is marked in an ingress module. At an egress module, 
the packets are counted using the block size as the counting 
modulus, and receipt of a marking packet triggers an update 
of the number of lost packets. 

BRIEF DESCRIPTION OF THE DRAWING 

FIG. 1 presents a block diagram of a switch in accordance 
with the principles disclosed herein; 

FIG. 2 illustrates the process of packet marking and 
counting; 

FIG. 3, presents an image of some of the fields in a local 
header of a packet flowing the FIG. 1 switch; 
FIG. 4 is a flow chart of the packet-marking process; and 
FIG. 5 is a flow chart of the packet counting process. 

DETAILED DESCRIPTION 

FIG. 1 presents a block diagram of a switch arrangement 
in accordance with the present disclosure. For the sake of 
illustration, it primarily refers to a single node, i.e., physical 
switch or router, but can be easily generalized to a logical 
group of nodes. Except for elements 12 and 32, and corre- 
sponding changes in switch controller 25, FIG. 1 depicts a 
conventional high-speed packet switch/router. That is, ele- 
ments 10(1), 10(2), . . . 10(N) are conventional ingress 
modules, except for the fact that each includes a marking 
module 12; switching fabric 20 is a conventional switching 
fabric; and egress modules 30(1), 30(2), . . . 30(N) are 
conventional egress modules, except for the fact that each 
includes a counting module 32. Switch controller 25 is also 
a conventional controller, except for its enhanced capabili- 
ties that are associated with interactions of elements 12 and 
32. 

As indicated above, it is important to be able to measure 
packet loss based on distinct, selected, traffic flows. A traffic 
flow can be defined in different ways, and at various degrees 
of granularity, depending on the user desires, or require- 
ments. For example, flow definition may be based on any 
subset or combination of the following criteria: 

an outgoing link (regardless of where the traffic 
originated); 

an egress module (regardless of where the traffic 

originated); 
an incoming/outgoing link pair; 
an ingress/egress module pair; 

a virtual connection identifier carried in the packet in 
connection-oriented networks; 

a packet source/destination pair in connectionless net- 
works; 

a traffic priority class; etc. 

If an incoming packet is only destined to one outgoing 
link, it is called a unicast packet. If it is destined to more than 
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one outgoing link, it is called a multicast packet. In the destined to egress module 30(2) and has the selected priority 

multicast case, the switching fabric will typically generate a level. When the counter reaches zero, the packet currently in 

copy of the same packet for each outgoing link. An unicast transmission is marked by setting a marking bit in the local 

packet can only associate with a single flow, but a multicast rout iqg header of the packet 

packet may associate with more than one flow (e.g., the flow 5 Qn ^ receivin sid counti module 32 

to S^w^ '^ to '!T \ fmr 1 module30(2)mamUmsaReceiverMarkmgCounter(RMC) 

The packet loss ; witmn the swatch arrangement of FIG. 1 m g ^ filock ^ BQ ^ ^ Ust V acke 

for a given traffic flow is generally characterized by the ratio _ ' rrnM „,. v ' a ~ • 

of the number of packetslhat do not make it to the outgoing C <T er ^ 323 measured flow - ™ e ™ C * * 

link(s), to the total number of packets that have been 10 B wrap-around down-counter, whereas both PBC 

received at the ingress link(s). and LPC are sa^rating up-counters with zero initial value. 

It is straightforward to associate a set of packet loss U P 0D flow admission, the RMC is initialized to B-l by 

counters with each known functional source of losses. The controller 25 so that a first packet in the flow that is 

group of losses caused by random glitches, however, associated with the value B-l at marking module 12 of 

remains hard (if at all possible) to detect and attribute to an 15 ingress module 10(1) is also associated with the value B-l 

appropriate flow. Besides, in a distributed switch design at RMC 321 within egress module 30(2). Subsequently, 

such as the one shown in FIG. 1, policing and buffering may RMC 321 is decremented upon receipt of every unmarked 

occur at multiple locations within a switch, thus making the packet belonging to the corresponding flow, which in the 

overhead of direct "at the loss source" measurements and the case of the instant illustration, means every packet that 

consolidations too high. Furthermore, since these critical 2 o arrives at module 30(2) that came from ingress module 10(1) 

locations are spatially distributed, a time coherence problem and which has the selected priority level. If, in addition, the 

may arise, i.e., measurements obtained at different buffering received relevant packet (packet belonging to the corre- 

location may not be synchronized. The last problem sponding flow) is marked, then the current value of RMC 

becomes even more severe if different buffers along the flow 321 is added to LPC 323 for the given flow, and then RMC 

path belong to different modules which are controlled 1S 321 itself is reset to B-l. The Packet Block Counter 323 

separately, and inter-module communication takes random, keeps track of the total number of packet blocks transmitted 

highly variable amount of time. and is incremented each time either a marked packet is 

To overcome the above problems, we measure packet loss received or the RMC is wrapped around and set to B-l in 

based on selected traffic flow from the input links to the the course of regular counting. The disclosed process makes 

output links. This is accomplished by identifying within 30 use of the fact that the value of the Receiver Marking 

ingress modules 10 the packets that belong to the selected Counter at the epoch immediately preceding receipt of a 

traffic flow, by counting and selectively marking those marked packcl is exactly to the number of packe ts, 

packets. In egress modules 30 those packets that belong to both marked and unmarked, that have been lost since the 

the same traffic flow are detected, and packet loss is ascer- receipt 0 f t he most recent marked packet; provided that this 

tained through reference to the markings placed by the 35 number is less than the block size, 

ingress modules. estimate of packet loss ratio for any given flow can be 

Our novel approach is explained in more detail below obtained on demand by taking a ratio between the corre- 

where, for the sake of illustration, it is assumed that the sponding lost packet counter LPC and the product of the 

desired packet loss measure is the one that corresponds to block size B and the packet block counter PBC. 

loss incurred by packets arriving at one selected ingress 40 FIG. 2 illustrates the disclosed process via an example 

module (e.g., 10(1)) that are destined to some selected egress wne re, for simplicity, the block size B is set to 6. 

module (e.g., 30(2)), and where the packets have a particular r ow 100 corresponds to the sequence of packets that 

selected priority class. For such a case, a traffic flow can be belong to a measured traffic flow; for example, the packets 

uniquely identified by a tuple(s,r,p), where s, r, and p that arrive at ingress module 10(1), have a selected priority 

indicate the ingress module, the egress module, and the 45 i eve i ^ m destined to egress module 30(2). The numbers 

priority class, respectively. In accordance with our approach, a bove row 100 designate the ordinal number of the packets 

two types of activities are primarily involved: below the numbers, and the numbers below the packets 

For each flow for which packet loss measurement is show the state of the counter within marking module 12 in 

supported, the sender (marking module 12 in ingress ingress module 10(1). 

module 10(1), for example) distinctively marks a 50 Row 110 presents the ideal case when no loss of packets 

packet at the end of each packet block of predefined occurs during the switching operation. In this case, LPC 323 

size. remains zero throughout the sequence because whenever a 

The receiver (counting module 32 at egress module 20(2), marked packet arrives, the value of RMC 321 is zero, so a 

for example) inspects the flow and infers the number of zero is "added" to LPC 323 with each transmitted block, 

losses between each pair of consecutively received 55 Separately, RMC 321 is reset by the marked packet to 5 (for 

marked packets, using the marked packets for synchro- the next packet) but, actually, RMC 321 would have reset 

nization. The knowledge of the block size allows the anyway. Resetting of RMC 321 also increments PBC 322. 

receiver to track the number of transmitted blocks even Row 120 presents a situation where the fourth packet in 

if marked packets themselves are lost. the illustrated sequence is lost. Because of the lost packet, 

Illustratively, marking module 12 of ingress module 10(1) 60 RMC 321-1 when the first marked packet arrives. This 1 is 

maintains a sender marking counter (SMC) for the identified added to the value held in LPC 323 when the marked packet 

flow. The SMC counter is a modulo B wrap-around down- resets RMC 321. As before, the reseting of RMC 321 

counter that upon flow admission is initialized to B-l by increments PBC 322. The next block arrives fully intact, a 

switch controller 25, where B is a predefined constant block value of zero is added LPC 323, resulting in LPC 323 

size agreed upon by both the sender and the receiver. This 65 maintaining the value 1, and PBC 322 is incremented again, 

counter is decremented each time a packet arrives to any of After these two blocks are completed, PBC322-2 and 

the input links of module 10(1), when such a packet is LPC323-1. The measure of lost packets at this time is 
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and marks packet C4. The other counter, which is associated 

lpc- 100 i • 100 with the flow between L and Y, counts packets 
, pr R ° TT a 8% 

^ ° z Bl, CI, C2, B2, B3, C3, C4, B4 

„ -„ , v . it _ - . A , .s and marks packet C3. Since both destinations X and Y 

Row 130 presents a situation where the fourth, sixth, and rcceive ^ of ^ ^ tf a 

tenth packets are lost It is particularly interesting to note mafkin bh wefe ^ ^ x and y destinations would 

that the sixth packet, which is a lost packet, is also a marked obserye both packets a ^ C4 ^ marked packets> and 

packet. The first row of numbers below the packets of row would be mMc t0 correctly identify which mar king per- 

130 indicates the state of RMC 321. Since the sixth packet 10 tains t0 their corresponding flow. The solution is to use 

is missing, RMC 321 is not reset by a marked packet but separate markings for the different multicast destinations, 

reset itself after six packets have arrived. When RMC 321 This j s achieved by sending a marking vector in the local 

does reset itself PBC 322 is incremented. When the twelfth routing header as illustrated, for example, in FIG. 3. The 

packet arrives, which is a marked packet, the state of RMC length of the vector, which corresponds to the number of 

321 is 3. The arrival of a marked packet signals the addition is different counts and different recipients of the packet, should 

of the state RMC 321 to the count in LPC 323. be limited to whatever upper bound is imposed by the 

Consequently, the value 3 is added to LPC 323, RMC 321 system on the multicasting process. For example, if the 

is reset, and the resetting of RMC 321 causes the value of system allows to multicast to at most M recipients, then the 

PBC 323 to be incremented. marking vector should accommodate M counts. 

FIG. 1 depicts marking module 12 to be associated with 20 It may be noted that the other fields shown to be associ- 

a processing and buffer module 11. Similarly, FIG. 1 depicts aled the Iocal header in FIG * 3 are fields that lhat 

counting module 32 to be associated with processing and assigned by the ingress modules. The "other fields" can 

buffer module 31. Based on the above, it follows that ™ chl6t such fields 35 me "incoming identifier'', "egress 

marking module 12 should logically be coupled to the traffic modu * e i dentifier "> "^tgoing link identifier", etc. 

flow ahead of all buffers and other elements within module 25 4 P rcBente . * chart of the P ro f » ca ™ d oui f 

, .«.« within marker module 12 for an arrangement where flows of 

11 where a packet might be dropped. Likewise, counting V. ' . . \. t y auanau^uj^i uuwlUYyju ' 

j i *<« l u, . « t_ i j. *i_ . «= a * different priorities are entertained, and a separate measure of 

T ft 1 1 ouldl ^ caU y^ TOU P led . t « the trafficflowpast ^ ^ fc desired for ^ * flQws Jq 

all of the buffers and other elements within module 31 where provide for to capabilitVj marker module 12 maimains a M 

a packet might be dropped. 3Q g xi of S MC(r,p) counters, where r^r,, r 2 , . . . , r„) and 

The description above dealt with a packet loss measure- p ^ p 2 , . . . , Pje ) are the vectors of supported receivers and 
ment for a particular chosen traffic flow. Of course, other priority classes, respectively. When a packet arrives, block 
traffic flow arrangements are possible, as indicated previ- 121 identifies the flow to which the packet belongs and 
ously. What is more significant to note is that many different passes control to block 122. In general, identification of the 
traffic flows can be concurrently measured. This is accom- 35 flow to which a packet belongs can be achieved by means of 
plished with a marker module 12 in each of ingress modules a flow identification table that is looked up by a local index 
which can establish any number of packet markers, and which is carried in the packet and contains the information 
likewise, with a counting module 32 in each of the egress about the destination within the switch and its priority class, 
modules which can establish any number of counter sets A priority class p is assigned to the packet according to a 
(RMC, PBC, and LPC). The maximum number of such sets <o congestion policy, which can be determined during a con- 
may conveniently be set to the number of input links so that nection setup in an ATM network, or based on a local policy 
the integrity of all links could easily be tested simulta- provisioned by a router. The destination information is 
neously. always required to switch packets correctly across the 

The above addresses traffic flow measurements for unicast switching fabric. From either information carried in the 

packets. In multi-casting, as indicated above, the switch is 45 P acket or stored in tne flow identification table, the indica- 

permitted to duplicate packets and to distribute the devel- ^on can be obtained whether the packet is unicast or 

oped plurality of packets to different specified output links. multicast. Let this destination information be in the form of 

In such a case, packet loss measurements cannot be achieved a receiver identifier vector d^d^dj, . . . 6 L ), where L^N is 

with a marker module and a counting module as disclosed me number of receivers (e.g., egress modules), that the 

above because packets are sent to different receivers (egress 50 packet will be trying to reach. In the case of a unicast packet, 

modules, or output links). The following example clarifies N is equal to one. 

the problem. Assuming a given incoming link L sends Block 122 decrements the corresponding SMC(r„p) 

packet in the sequence counter for that flow, repeating for each value of i up to L. 

Thereafter, control passes to block 123 where it is ascer- 

ai, A2, Bl, Ci, C2, B2, B3, C3, C4, A3, B4 55 tained whether any of the marking counters SMC(r ( ,p) 

reached zero for any value of i. For those values of i that the 

where A designates a unicast packet addressed to destination marking counter did reach zero, the packet is marked, and 

X, B designates a unicast packet addressed to destination Y with the next relevant packet the SMC(r,-,p) counter is set to 

(perhaps in a different egress module than destination 1), and B-l . 

C designates a mulitcast packet addressed to both destina- 60 FIG. 5 presents a flow chart of the process carried out in 

tion X and destination Y. If packet loss measurements are in counting module 32, corresponding to the process carried 

effect for two flows, between L and X, and between L and out in marking module 12. Specifically, on the egress side, 

Y, using, for example, block size 6, then clearly two marking three sets of counters per flow are maintained by a receiver 

counters are needed. The one associated with the flow r within counting module 32: RMC(s,p), LPC(s,p), and 

between L and X counts the following packets 65 PBC(s,p), where s«(s 1 , S2, . . . , S^) and p^fo, p 2 » . . . » Px) 

are the sender and priority vectors, respectively. Upon 

ai, A2, ci, C2, C3 f C4, A3, arrival of a packet, block 301 determines the sender's 
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identifier s and the priority p by reading the values of the 
appropriate fields in the local header of the packet, accepts 
the packet as belonging to the traffic flow being counted, if 
appropriate, and passes control to block 302 which decre- 
ments RMC(s,p). Thereafter, block 303 examines the M(r, p) 5 
bit in the packet's local header. If the bit is set, which means 
that the packet is marked, control passes to block 305 where 
the current value of RMC(s, p) is added to the counter of the 
lost packets, LPC(s, p). Thereafter, block 307 sets RMC(s,p) 
to zero and passes control to block 306 where block counter 10 
PBC(s,p) is incremented. If block 303 determines that the 
considered packet is not a marked packet, control passes to 
block 304 where a test is performed to determine whether 
counter RMC(s,p) is already at zero. When such is the case, 
control passes to block 306 where the block counter PBC 15 
(s,p) is incremented. When decision block 304 finds the 
RMC(s,p) is not already at zero, control passes to block 308, 
as it does following action of block 306. Finally, block 308 
detaches the local routing header inserted at an ingress 
module and transmits the packet to an outgoing link. 2 o 

The proposed packet loss measurement method can be 
easily extended to support loss measurements for aggregated 
flows having a single destination (receiver) but multiple 
sources (senders) and/or priority classes. While a separate 
Marking Counter RMC(s,p) is maintained by receiver r for 2 s 
each sender-receiver pair and priority class, only single Lost 
Packet Counter LPC(f) and single Packet Block Counter 
PBC(f) are required for an aggregated flow f. While receipt 
of unmarked packets from sender s and with priority p still 
causes a decrementing of an individual RMC(s,p) counter, 30 
the same LPC(f) and PBC (f) counters are updated no matter 
on which leg of a multipoint-to-point flow a marked packet 
is received and to which priority class it belongs, using 
multiple RMC(s,p) counters. The receiver's algorithm in this 
case can easily be modified to take into account this effect 35 
since the aggregated counters LPC and PBC operate in a 
similar way as previously described. This modification leads 
to a significant reduction in the number of counters required, 
and it is especially true for a switch with a large number of 
ingress and egress modules. 40 

As might have been observed from the illustrative 
example presented above, the disclosed process permits a 
straightforward characterization of the packet loss for a 
given traffic flow. Specifically, the packet loss ratio can be 
assessed in terms of the number of packets lost compared to 45 
the total number of packets successfully transmitted. This 
can be done merely by considering the information available 
within counting module 32. Specifically, a packet loss ratio 
can be expressed in terms of 

50 

LPQs, p) 
PLR(s, r, p) = 1_L*Z_. 

In a real environment when the switch is operating user 
traffic dynamically changes with time. It is of practical 55 
interest to monitor and measure packet loss in a continuous- 
time fashion, although packet loss is bound to be time- 
dependent. One way to obtain a continuous reading is to 
periodically perform the packet loss ratio calculation, to 
reset all counter and start again, and to combine the 60 
periodically-obtained values in some manner that makes 
sense. For example, a smoothing function can be employed 
of the type 

where PLR CU(WU is the newly computed running "average" 
value, PLR WM/ is the new current packet loss ratio, PLR^ WV 
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is the immediately previous running "average", and a is a 
selected decay factor. The frequency with which these 
computation takes place is, of course, a design choice. 

As for the method of implementation, it may be noted that 
the various counters disclosed above are very simple 
counters that can be implemented with specific integrated 
circuit cards that are plugged into the ingress and egress 
modules. Those cards can also comprise a microprocessor 
that is programmed to implement the counters and to com- 
municate with controller 25 (e.g., to send the controller the 
various counts, and to synchronize themselves to the con- 
troller's control signals). 

we claim: 

1. A system comprising ingress links, egress links, and 
apparatus interposed between said ingress and egress finks, 
which system is adapted to measure packet loss on a traffic 
flow basis, the improvement comprising: 

a first marking module associated with at least a first 
ingress link of said ingress links, where said marking 
module marks only one packet in each block of N 
packets, where N is a selected integer, belonging to a 
first packet flow, and 

a counting module employed during operational mode of 
said system, associated with at least one of said egress 
links that measures, with the aid of information 
imparted by said marking module, packet loss within 
said system relative to number of packets of said first 
packet flow that are successfully transmitted by said 
system. 

2. The system of claim 1 where said block of packets 
comprises a given number of packets that belong to said 
given packet flow. 

3. The system of claim 1 where said marking module is 
associated with more than one of said ingress links. 

4. The system of claim 1 further comprising: 

ingress modules, each of which is coupled to a preselected 

number of said ingress links, and 
egress modules, each of which is coupled to a preselected 

number of said egress links; 
where said first marking module is included in at least one 

of said ingress modules, and said counting module is 

included in at least one of said egress modules. 

5. The system of claim 4 where said first packet flow is set 
to correspond to any one or a combination of the following: 

packets of a given source, 
packets arriving at said first link, 
packets arriving at said ingress module 
packets destined to a given egress module 
packets having a given virtual connection identifier, 
packets having a given source and destination pair, 
packets destined to a given destination, 
packets destined to a given egress link, 
packets having a given priority. 

6. The system of claim 5 where said first marking module 
is coupled to all ingress links associated with said first 
marking module. 

7. The system of claim 1, further comprising at least one 
additional marking module that is associated with a different 
ingress link and which marks a second packet flow. 

8. The system of claim 7 where said counting module 
comprises: 

a first receiver marking counter which is a wrap-around 
down counter synchronized to said first marking 
module, and decremented upon arrival of each packet 
belonging to said first packet flow, 
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a second receiver marking counter which is a wrap- 
around down-counter synchronized to said additional 
marking module and decremented upon arrival of each 
packet belonging to a packet flow marked by said 
additional marking module, 5 

a first packet block counter that is incremented whenever 
said first receiver marking counter reaches a given 
state, 

a second packet block counter that is incremented when- 
ever said second receiver marking counter reaches a 
given state, and 

a lost packet counter that is incremented with the state of 
said first receiver marking counter upon arrival of a 
marked packet belonging to said first packet flow, and s 
incremented with the state of said second receiver 
marking counter upon arrival of a marked packet 
belonging said packet flow marked by said additional 
marking module. 

9. The system of claim 1 further comprising additional 2Q 
counting modules that are associated with different egress 
links. 

10. The system of claim 1 further comprising: 

a first plurality of ingress modules, each of which is 
associated with a first plurality of ingress links, 2 S 

a second plurality of egress modules, each of which is 
associated with a second plurality of egress links, 

a first plurality of marking modules, one of whom is said 
first marking module, where each marking module of 
said first plurality of marking modules is associated 30 
with one ingress module of said plurality of ingress 
modules, and 

a second plurality of counting modules, one of whom is 
said counting module, where each counting module of 
said second plurality of counting modules is associated 35 
with one egress module of said plurality of egress 
modules. 

11. The system of claim 1 where said first marking module 
comprises a counter that counts incoming packets belonging 
to said first packet flow, and marks a packet whenever said 
counter reaches a preselected state. 

12. The system of claim 11 where said first marking 
modules marks a packet by setting a bit in a header that is 
attached to packets of said first packet flow. 

13. The system of claim 11 where said counting module 45 
comprises: 

a first plurality of receiver marking counters, each of 
which is a wrap-around down counter synchronized to 
a marking module, and decremented upon arrival of 5Q 
each packet belonging to a packet flow marked by the 
marking module with which the receiver marking 
counter is synchronized, 

a first plurality of lost packet counters, each of which is 
associated with one of said first plurality of receiver 55 
marking counters and is incremented with the state of 
its associated receiver marking counter upon arrival of 
a marked packet belonging to a packet flow marked by 
a marking module with which the associated receiver 
marking counter is synchronized, and 60 

a packet block counter that is incremented whenever any 
of said first plurality of receiver marking counters 
reaches a given state. 

14. Trie system of claim 11 where said counting module 
comprises: 65 

a first plurality of receiver marking counters, each of 
which is a wrap-around down counter synchronized to 
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a marking module, and decremented upon arrival of 
each packet belonging to a packet flow marked by the 
marking module with which the receiver marking 
counter is synchronized, 

a first plurality of lost packet counters, each of which is 
associated with one of said first plurality of receiver 
marking counters and is incremented with the state of 
its associated receiver marking counter upon arrival of 
a marked packet belonging to a packet flow marked by 
a marking module with which the associated receiver 
marking counter is synchronized, and 

a first plurality of packet block counters, each of which is 
associated with one of said first plurality of receiver 
marking counters and is incremented whenever its 
associated receiver marking counter reaches a given 
state. 

15. The system of claim 11 where said counting module 
comprises: 

a receiver marking counter that is a wrap-around down 
counter synchronized to said counter of said first mark- 
ing module, and decremented upon arrival of each 
packet belonging to said first packet flow, 

a lost packet counter that is incremented with the state of 
said receiver marking counter upon arrival of a marked 
packet belonging to said first packet flow, and 

a packet block counter that is incremented whenever said 
receiver marking counter reaches a given state. 

16. The system of claim 15 further comprising a controller 
coupled to said lost packet counter and to said packet block 
counter, for developing a measure of packets lost in relation 
to packets successfully transmitted. 

17. The system of claim 16 further comprising a module 
that incorporates the developed measure of packets lost into 
an average measure, and resets the lost packet counter. 

18. The system of claim 17 where the said module that 
develops said average measure performs the calculation 
PLR^ m -aPLR^l^)PLR pnfV , where ?LR cumm is a 
currently computed value of said average measure, PLR^.^ 
is a current packet loss ratio evaluated by dividing the value 
contained in the lost packet counter by the product of the 
size of said block and the value contained in the packet block 
counter, PLRp WV is the immediately previous value of said 
average measure, and a is a selected decay factor. 

19. The system of claim 1 where said first packet flow is 
set to correspond to any one or a combination of the 
following: 

packets of a given source, 

packets arriving at said first link, 

packets having a given virtual connection identifier, 

packets having a given source and destination pair, 

packets destined to a given destination, 

packets destined to a given egress link, 

packets having a given priority. 

20. The system of claim 1 where said system is a packet 
switch or router. 

21. The system of claim 1 where said system is a logical 
group of switches or routers. 

22. A method for measuring packets lost in a system that 
includes an ingress module responsive to a plurality of input 
links, an egress module coupled to a plurality of output links, 
and a system including a transmission medium interposed 
between said ingress module and said egress module, com- 
prising the steps of: 

at the ingress module 
inspect incoming packets to identify packets that 
belong to a preselected traffic flow, 
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responsive to each identified packet that belongs to said 
preselected traffic flow, increment a wrap-around 
counter, 

mark an identified packet when said counter reaches a 

given state, and 
at an egress module 
inspect incoming packets to identify packets that 

belong to a preselected traffic flow, 
responsive to each identified packet that belongs to said 

preselected traffic flow, advance a wrap-around 

down-counter, 
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increment a packet block counter whenever said wrap- 
around down-counter reaches a given state, and 

increment a lost packet counter with the state of said 
wrap-around down-counter when an identified 
packet is marked, and reset said wrap-around down- 
counter. 

23. The method of claim 22 further comprising a step of 
developing a measure of average number of packets lost per 
block. 
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